Multicasting, as used herein, refers to the transmission of the same information in packets by a source to a multiplicity of receivers in a packet switched communications network.
There are two major steps in multicasting: multicast routing for establishing a desirable connection, and data forwarding for switching of packets at each intermediate switching node along the path. Multicast routing establishes a delivery route through which information packets can be exchanged efficiently among participants. The plurality of participants that exchange common data is referred to as groups.
Known internet protocols allow the establishment of multicasts on Internet Protocol (“IP”) compliant networks. A commonly supported IP protocol, referred to as the Internet Group Management Protocol (“IGMP”) is detailed in the Internet Engineering Task Force, Request for Comments, (“RFCs”) 1112, 1122, 1812, 2236, 2715, 2933, and 3228.
Often, two or more established groups may wish to merge and later disband, to exchange data of common interest, increasing the flexibility in sharing data and supporting collaboration. The current IP multicast implementations, however, do not provide for graceful merging and disbanding of multiple groups. That is, they allow a host to join and leave a multicast group, but do not support a group to join another group as a unit. Thus to have the effect of a group of hosts (group X) joining another group of hosts (group Y), all members of group X individually join the group Y. The cost, in terms of network traffic, of having individual members joining and leaving increases rapidly with the number of members present in a group. As such, this approach is undesirable in most practical networks in which memberships may change frequently.
In addition, a host typically maintains open one port to listen to each group it wants to join. This form of implementation limits the total number of ports, and hence groups, a host can join. If there is a constraint on the number of ports a host can listen to, a host may have to leave some multicast groups to reuse these ports. This may cause the property of the original group setup to be lost.
As an alternative, a list defining the merge status of each group could be maintained at the application level. This however requires higher protocol processing as each packet needs to traverse up the IP stack, the transport stack and then onto the application layer before a decision can be made for sending the packet to a group. Hence, high transmission and protocol overhead will be incurred if the merge status of groups is maintained at the application level.
The constraints and limitations of existing IP multicast methods above have hampered the development of innovative group communication services for collaborative applications. Clearly, there is a need to provide a simple and yet powerful multicast architecture to support group operations in a packet switched network.